The present invention relates in general to the field of computer system emulation and, more particularly, to a system and method for the handling of software instructions directed to the processor of the computer system from an emulated computer system.
Computers include general purpose central processing units (CPUs) that are designed to execute a specific set of system instructions. A group of processors that have similar architecture or design specifications may be considered to be members of the same processor family. Examples of current processor families include the Motorola 680X0 processor family, manufactured by Motorola, Inc. of Phoenix, Ariz.; the Intel 80X86 processor family, manufactured by Intel Corporation of Sunnyvale, Calif.; and the PowerPC processor family, which is manufactured by Motorola, Inc. and used in computers manufactured by Apple Computer, Inc. of Cupertino, Calif. Although a group of processors may be in the same family because of their similar architecture and design considerations, processors may vary widely within a family according to their clock speed and other performance parameters.
Each family of microprocessors executes instructions that are unique to the processor family. The collective set of instructions that a processor or family of processors can execute is known as the processor's instruction set. As an example, the instruction set used by the Intel 80X86 processor family is incompatible with the instruction set used by the PowerPC processor family. The Intel 80X86 instruction set is based on the Complex Instruction Set Computer (CISC) format. The Motorola PowerPC instruction set is based on the Reduced Instruction Set Computer (RISC) format. CISC processors use a large number of instructions, some of which can perform rather complicated functions, but which require generally many clock cycles to execute. RISC processors use a smaller number of available instructions to perform a simpler set of functions that are executed at a much higher rate.
The uniqueness of the processor family among computer systems also typically results in incompatibility among the other elements of hardware architecture of the computer systems. A computer system manufactured with a processor from the Intel 80X86 processor family will have a hardware architecture that is different from the hardware architecture of a computer system manufactured with a processor from the PowerPC processor family. Because of the uniqueness of the processor instruction set and a computer system's hardware architecture, application software programs are typically written to run on a particular computer system running a particular operating system.
A computer manufacturer will want to maximize its market share by having more rather than fewer applications run on the microprocessor family associated with the computer manufacturer's product line. To expand the number of operating systems and application programs that can run on a computer system, a field of technology has developed in which a given computer having one type of CPU, called a host, will include an emulator program that allows the host computer to emulate the instructions of an unrelated type of CPU, called a guest. Thus, the host computer will execute an application that will cause one or more host instructions to be called in response to a given guest instruction. Thus, the host computer can both run software designed for its own hardware architecture and software written for computers having an unrelated hardware architecture. As a more specific example, a computer system manufactured by Apple Computer, for example, may run operating systems and program written for PC-based computer systems. It may also be possible to use an emulator program to operate concurrently on a single CPU multiple incompatible operating systems. In this arrangement, although each operating system is incompatible with the other, an emulator program can host one of the two operating systems, allowing the otherwise incompatible operating systems to run concurrently on the same computer system.
When a guest computer system is emulated on a host computer system, the guest computer system exists as a virtual machine, as the guest computer system exists only as a software representation of the operation of the hardware architecture of the guest computer system. The terms emulator and virtual machine are sometimes used interchangeably to denote the ability to mimic or emulate the hardware architecture of an entire computer system. As an example, the Virtual PC software created by Connectix Corporation of San Mateo, Calif. emulates an entire computer that includes an Intel 80X86 Pentium processor and various motherboard components and cards. The operation of these components is emulated in the virtual machine that is being run on the host machine. An emulator program executing on the operating system software and hardware architecture of the host computer, such as a computer system having a PowerPC processor, mimics the operation of the entire guest computer system. The emulator program acts as the interchange between the hardware architecture of the host machine and the instructions transmitted by the software running within the emulated environment.
The emulation program may reside as an application program that runs on the host operating system. The emulation program will in turn emulate the operation of the guest computer system. If the host computer system and the guest computer system are designed to operate on two different microprocessor families, the emulator program must translate instructions intended to be executed by the guest microprocessor family into instructions that can be executed by the processor of the host computer system. In doing so, the emulator program dynamically translates blocks or groups of instructions destined for the microprocessor family of the emulated computer system to a set of instructions that are executable, following compilation if necessary, by the processor of the host computer system.
As the software or hardware of a computer system improves over time to accommodate technological or design advances, it is desirable that backward compatibility be provided for legacy software written for prior versions of the software or hardware of the computer system. One example of backward compatibility involves emulation programs that emulate a DOS environment. An emulation program running as an application in a Windows operating system can emulate a DOS environment, allowing application programs written for DOS to execute. The DOS-based application program executes as though the DOS operating system is in logical control of the computer system, when in fact Windows or some other host operating system is in logical control of the operating system. In this example, because the processor associated with the Windows host operating system and the processor associated with the DOS operating system are in the same processor family, the code associated with application programs written for the DOS operating system can be run directly on the processor of the computer system. Emulation is desirable in this example because the DOS operating system expects to be in logical control of the hardware of the computer system. By emulating the DOS operating system in the host operating system, the DOS code can execute on the computer system without the necessity of forcing the Windows operating system to give up logical control of the computer system. Windows remains in logical control of the operating system, permitting all Windows-based functionality, including all I/O functionality, of the computer system to continue to function.
Typically, a modem processor will include two operating modes: user level and supervisor level. When the processor is at supervisor level, the processor can execute every instruction in the processor's instruction set. When the processor is operating at user level, the processor can execute only a subset of the instructions of the instruction set. Most of the instructions in the processor instruction set are executable irrespective of whether the processor is operating at user level or supervisor level. There are a limited set of instructions that cannot be executed when the processor is in user mode. If the processor is presented with an impermissible instruction when the processor is in user mode, an exception would be generated, and the processor would switch to supervisor mode.
When a computer system boots, the processor is operating at supervisor level. Likewise, the processor operates at supervisor level when the operating system is in control of the processor. The operating system will at some point pass control of the computer system to a software program, such as application program, that can execute with a processor that is running in user mode. When this occurs, the operating system issues a command that causes the processor to switch from supervisor mode to user mode. There is not a similar command that the application program can issue to cause the processor to switch from user mode to supervisor mode. If the application program passes to the processor an impermissible instruction, i.e., an instruction that cannot be executed by the processor when the processor is in user mode, an exception will be generated, causing the operating system to gain control of the processor and causing the processor to switch to supervisor mode. If the application program does not perform an illegal operation, the application program can maintain control of the computer system indefinitely and the processor will continue to operate at user mode. A computer system will generally have a timer that will cause an interrupt to be generated at regular intervals, allowing the processor to switch to supervisor mode and allowing the operating system to regain control of the processor.
Because most application programs execute with a processor that is running in user mode, the functions that may be performed by the application program are somewhat limited. Software that operates in user mode cannot manipulate the computer system's settings and resources. User level software, for example, cannot write to certain privileged memory locations or take other actions that would compromise the stability or cause the malfunction of the computer system. If an application program were to attempt to perform such a function, an exception would be generated. When an exception is issued, the processor halts execution of the user level code and transitions to a supervisor level exception handler that was previously installed by the operating system. As another example, if an application program attempts to write to a page of a virtual memory system that has not yet been mapped into the page table maintained by the operating system, a page fault exception will occur. When the page fault occurs, control passes to the supervisor level code of the operating system, which maps in the virtual page requested by the user level code. After mapping in the page requested by the application program, the processor switches from supervisor mode to user mode, returning control to the application program.
In the DOS operating system environment, the processor always operated at supervisor mode. Thus, all application programs for DOS, as well as DOS itself, executed at the supervisor level. As a result, every piece of software for DOS, whether at an operating system level or an application program level, is written for a processor that will execute at supervisor mode. When an emulation program emulates the operation of a DOS operating system for an application program written for the DOS operating system, the use of code in the application program that is written for a processor executing at supervisor mode presents a difficulty in that the application programs include code that cannot be executed on a processor running at user level. Further, another difficulty of emulated DOS programs is that emulated DOS programs may attempt to establish their own set of exception handlers or perform other housekeeping functions, such as turning interrupts on and off. Because these DOS programs execute on a processor running at supervisor level, these programs are able to perform functions or modify settings of the computer system in a manner that is typically reserved for the operating system, creating a potential conflict for logical control of the computer system between the host operating system and the software running in an emulated DOS environment.
When emulating the operation of an operating system that was designed to operate with the processor of the host operating system, the emulator program is faced with the task of emulating code that is intended to run on a processor at supervisor level and code that is intended to run on a processor at user level. The emulated guest operating system may attempt to perform certain functions with code that is intended to operate at supervisor level that would either interfere with the operating system settings established by the host computer or reveal to the guest operating system that it is emulated and is not in actual control of the computer system. In this environment, where the host computer system and the guest computer system are both associated with the same processor or processor family, handling the software of the guest computer system can be problematic in that the guest computer system includes software code that runs at user level and software code that runs at supervisor level. Directly executing all of the code of the emulated computer system may allow the emulated computer system to compromise the integrity of the host operating system, and translating or buffering all of the code of the guest computer system will introduce an undesirable performance drag in the emulation of the guest computer system.